Modify some parser diagnostics to continue evaluating beyond the parser #57540

estebank · 2019-01-12T07:20:58Z

Continue evaluating further errors after parser errors on:

trailing type argument attribute
lifetime in incorrect location
incorrect binary literal
missing for in impl Trait for Foo
type argument in where clause
incorrect float literal
incorrect .. in pattern
associated types
incorrect discriminator value variant error

and others. All of these were found by making continue-parse-after-error true by default to identify errors that would need few changes. There are now only a handful of errors that have any change with continue-parse-after-error enabled.

These changes make it so rust won't stop evaluation after finishing parsing, enabling type checking errors to be displayed on the existing code without having to fix the parse errors.

Each commit has an individual diagnostic change with their corresponding tests.

CC #48724.

rust-highfive · 2019-01-12T07:21:08Z

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

petrochenkov · 2019-01-12T18:55:03Z

Is it possible to flip the default and introduce span_err_irrecoverable or something for errors that stop compilation?
This way it will be obvious what cases still need fixing.
(Also replacing span_err(span, msg) with struct_span_err(span, msg).emit() will be unnecessary.)

petrochenkov · 2019-01-12T18:59:16Z

In the previous PRs (#57379, #57272 etc) I adjusted tests so they don't report errors that are not related to the point of the test and are not consequences of recovery (e.g. unresolved names, missing main).
I'll go through the tests and mark the errors that I think are "off-topic" and are better avoided.

src/test/ui/attrs-with-no-formal-in-generics/attrs-with-no-formal-in-generics-3.stderr

src/test/ui/parser/issue-14303-fncall.stderr

src/test/ui/parser/issue-14303-path.stderr

src/test/ui/parser/issue-1802-2.stderr

src/test/ui/parser/pat-tuple-2.stderr

src/test/ui/parser/pat-tuple-3.stderr

src/test/ui/parser/tag-variant-disr-non-nullary.stderr

estebank · 2019-01-13T03:32:46Z

r? @petrochenkov

Is it possible to flip the default and introduce span_err_irrecoverable or something for errors that stop compilation?
This way it will be obvious what cases still need fixing.
(Also replacing span_err(span, msg) with struct_span_err(span, msg).emit() will be unnecessary.)

Makes sense.

EDIT: I just realized that we still need to use struct_span_err directly in most places, as we're also adding suggestions/labels. I won't pursue changing span_err as it will have little improvement. The only thing that would be useful is maybe renaming span_err to span_err_irrecoverable as proposed.

In the previous PRs (#57379, #57272 etc) I adjusted tests so they don't report errors that are not related to the point of the test and are not consequences of recovery (e.g. unresolved names, missing main).

I'd like to have some regression tests to make sure that the parser doesn't suddenly start blocking further processing again by accident. Do you think it makes sense to have a few marked explicitly that way?

estebank · 2019-01-13T03:34:31Z

src/test/ui/attrs-with-no-formal-in-generics/attrs-with-no-formal-in-generics-3.stderr

   |
-LL |     where Q: for <#[rustc_1] 'a, 'b, #[oops]> Fn(RefIntPair<'a,'b>) -> &'b u32
-   |                                      ^^^^^^^
+LL |     where Q: for <#[allow(unused)] 'a, 'b, #[oops]> Fn(RefIntPair<'a,'b>) -> &'b u32


I didn't know we could have attributes annotating lifetimes, 2) we have no attributes to annotate lifetimes or type arguments at this time :)

petrochenkov · 2019-01-13T11:35:17Z

The only thing that would be useful is maybe renaming span_err to span_err_irrecoverable as proposed.

Hmm, looks like that would require touching a lot of other code because behavior of span_err changes dynamically from irrecoverable to recoverable.
Ok, let is stay as is for now.

I'd like to have some regression tests to make sure that the parser doesn't suddenly start blocking further processing again by accident. Do you think it makes sense to have a few marked explicitly that way?

Yes, it would be good to have a single dedicated test rather than "accidental" errors here and there.

petrochenkov · 2019-01-13T11:35:32Z

@bors r+

bors · 2019-01-13T11:35:33Z

📌 Commit 28ea03e has been approved by petrochenkov

Modify some parser diagnostics to continue evaluating beyond the parser Continue evaluating further errors after parser errors on: - trailing type argument attribute - lifetime in incorrect location - incorrect binary literal - missing `for` in `impl Trait for Foo` - type argument in `where` clause - incorrect float literal - incorrect `..` in pattern - associated types - incorrect discriminator value variant error and others. All of these were found by making `continue-parse-after-error` `true` by default to identify errors that would need few changes. There are now only a handful of errors that have any change with `continue-parse-after-error` enabled. These changes make it so `rust` _won't_ stop evaluation after finishing parsing, enabling type checking errors to be displayed on the existing code without having to fix the parse errors. Each commit has an individual diagnostic change with their corresponding tests. CC rust-lang#48724.

@ghost

Rollup of 8 pull requests Successful merges: - #57043 (Fix poor worst case performance of set intersection) - #57480 (Clean up and fix a bug in query plumbing) - #57481 (provide suggestion for invalid boolean cast) - #57540 (Modify some parser diagnostics to continue evaluating beyond the parser) - #57570 (Querify local `plugin_registrar_fn` and `proc_macro_decls_static`) - #57572 (Unaccept `extern_in_paths`) - #57585 (Recover from item trailing semicolon) - #57589 (Add a debug_assert to Vec::set_len) Failed merges: r? @ghost

estebank added 12 commits January 11, 2019 19:31

Continue parser after trailing type argument attribute

5c67ba6

Continue parsing after lifetime in incorrect location

fc4b541

Continue evaluating after parsing incorrect binary literal

d8610b3

Continue evaluating after missing for in impl Trait for Foo

5d2f31c

Continue evaluating after type argument in where clause

57f17e9

fix tests

65a8d7b

Continue evaluating after incorrect float literal

8bede50

fix test

975f8b5

Continue evaluating after finding incorrect .. in pattern

8119017

Tweak type argument after assoc type error

de3c4be

Small tweaks to parser errors

7feb802

Tweak incorrect discriminator value variant error

3ead6de

rust-highfive assigned pnkfelix Jan 12, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 12, 2019

Add label for invalid literal suffix

1550787

petrochenkov assigned petrochenkov and unassigned pnkfelix Jan 12, 2019

petrochenkov reviewed Jan 12, 2019

View reviewed changes

petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 12, 2019

estebank added 2 commits January 12, 2019 17:12

Remove unrelated errors from parse stderr tests

db74031

Suggest correct location for lifetime parameters in use

28ea03e

estebank commented Jan 13, 2019

View reviewed changes

estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 13, 2019

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 13, 2019

Centril mentioned this pull request Jan 14, 2019

Rollup of 5 pull requests #57599

Closed

Centril mentioned this pull request Jan 14, 2019

Rollup of 8 pull requests #57607

Merged

bors merged commit 28ea03e into rust-lang:master Jan 15, 2019

petrochenkov mentioned this pull request Dec 31, 2019

parser: reduce diversity in error handling mechanisms #67744

Merged

estebank deleted the eval-more branch November 9, 2023 05:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Modify some parser diagnostics to continue evaluating beyond the parser #57540

Modify some parser diagnostics to continue evaluating beyond the parser #57540

estebank commented Jan 12, 2019

rust-highfive commented Jan 12, 2019

petrochenkov commented Jan 12, 2019

petrochenkov commented Jan 12, 2019

estebank commented Jan 13, 2019 •

edited

Loading

estebank Jan 13, 2019

petrochenkov commented Jan 13, 2019

petrochenkov commented Jan 13, 2019

bors commented Jan 13, 2019

Modify some parser diagnostics to continue evaluating beyond the parser #57540

Modify some parser diagnostics to continue evaluating beyond the parser #57540

Conversation

estebank commented Jan 12, 2019

rust-highfive commented Jan 12, 2019

petrochenkov commented Jan 12, 2019

petrochenkov commented Jan 12, 2019

estebank commented Jan 13, 2019 • edited Loading

estebank Jan 13, 2019

Choose a reason for hiding this comment

petrochenkov commented Jan 13, 2019

petrochenkov commented Jan 13, 2019

bors commented Jan 13, 2019

estebank commented Jan 13, 2019 •

edited

Loading